#git worktree mode
Explore tagged Tumblr posts
Text
I'm thinking that `git-worktree-mode` eventually becomes just one subcommand of a more fully-featured command.
In particular, I'm seeing a lot of value now in replacing `git worktree add`, to solve some problems:
Git uses absolute paths for everything worktree-related internally. This normally doesn't matter but will blindside you with problems if you ever move the repo folder or any of the worktree folders. Recent `git` versions have `git worktree repair` to fix this, so that's not too bad, but it's still annoying.
`git worktree add foo` always creates a new `foo` branch if no local `foo` branch exists, even if a remote branch named `foo` exists. To get "normal" behavior for remote branches, like what `git checkout foo` does, you need to do `git worktree add foo foo`. If you forget that, it is annoying and non-obvious to fix.
3 notes
·
View notes
Text
As foretold (by me) in the prophesies a couple rambling posts, my efforts to achieve a great briefly exciting (for me) workflow with multiple Git work trees have "matured" (I spent a few says compulsively thinking about it every once in a while) into `git-cotree`.
`git-worktree-mode` became `git-cotree --init`. The new functionality is "just" ergonomically and robustly creating and deleting work trees co-trees, CLI argument parsing, and help text.
It is the same `git` history/repository (so you can still get your hands on the earlier work , I just renamed it in GitHub (so the old GitHub repo URL should redirect to the new one into the indefinite future).
2 notes
·
View notes
Text
Feel free to file GitHub issues or reach out on here if you have problems with `git-worktree-mode` on older Git versions.
It works fine on Git 2.31.
It had at least three breakages for me on Git 2.15, but I decided not to bother committing any of the patches after the second, and stopped investigating after the third. When it comes to my own needs, currently I might as well just solve that problem in other ways on a case-by-case basis if I need to, rather than try to support it in the script source.
But if any of you are running into issues with it on older Git versions, I'd like to know, so I can take it into consideration.
1 note
·
View note
Text
So worktree-centric Git usage is not worth it for small repos with little if any concurrent contributions.
When I `git clone` one of my personal projects just to make a quick change, I'm definitely not itching to put my repo into worktree mode. When I am creating a new repo from scratch, worktree mode also kinda just gets in the way. Because in those cases, I never feel the want for more than one working directory.
It mostly becomes worth it once you have a larger, more complex code base, or a larger, busier team. Basically, the usefulness grows in proportion to how much and how often you find yourself switching between branches. I find that it especially helps making it painless to pull changes apart into multiple separate branches, which can tremendously help with code review, and can also separate contentious or unfinished pull requests from other changes that the team can benefit from immediately.
That's a big part of why I'm so happy with my current worktree-centric approach - it means that with a script like git-worktree-mode can provide a very smooth upgrade path! The user experience is that when you feel you need multiple worktrees, you just run the script, get a setup which is extremely ergonomic for multiple worktrees, and move on with your work, all with barely an interruption.
1 note
·
View note
Text
git-worktree-mode
I have put a script on my GitHub to automatically convert a Git repository into the very slick setup for a worktree-centric workflow that I seem to have discovered.
The script takes care of a lot of little edge cases that my previous explanations didn't bother covering, that's why it's got so much stuff going on.
Specifically, it's trying to make sure it fails fast with a clear Git error message if you use it wrong, and it tries to automatically migrate your current working directory and any uncommitted changes you had into a worktree.
1 note
·
View note